Info-Atari16 Digest Fri, 24 Jan 92 Volume 92 : Issue 41 Today's Topics: Amiga geeks, read this Atarians! Where Are You?! (2 msgs) blitter questions Hyperformat disk on a PC I cant get Zoo to work! Model questions Multifinder for Atari-ST ? New Supra Modem... PRGFLAGS review (was talk about Tcsh) Rom chip set switch time? SST shipdate & Gadgets news What to do? Yet another ST for sale Welcome to the Info-Atari16 Digest. The configuration for the automatic cross-posting to/from Usenet is getting closer, but still getting thrashed out. Please send notifications about broken digests or bogus messages to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU. Please send requests for un/subscription and other administrivia to Info-Atari16-Request, *NOT* Info-Atari16. Requests that go to the list instead of the moderators are likely to be lost or ignored. If you want to unsubscribe, and you're receiving the digest indirectly from someplace (usually a BITNET host) that redistributes it, please contact the redistributor, not us. ---------------------------------------------------------------------- Date: 24 Jan 92 00:02:00 GMT From: fernwood!portal!cup.portal.com!Azog-Thoth@uunet.uu.net (William Thomas Daugustine) Subject: Amiga geeks, read this To: Info-Atari16@naucse.cse.nau.edu If you are an Atari ST user, and have no desire to move to an Amiga quit out of this. If you are an Amiga user who insists on posting derogatory article GET THE FUCK OUT OF HERE. Notice the name of this news group? It is "comp.sys.ATARI.st". That ATARI means ATARI, not AMIGA. Go play in your own amiga land. There is one asshole: Gregory Miller england@milton.u.washington.edu, who seems to feel the need to bash the Atari. Maybe he has his own feelings of insecurity? Once again, GET THE HELL OUT OF HERE. Go kill yourself, get a life, die, we wont miss you. Post on your own goddamned newsgroups about how bad Atari is. I dont read any Amiga newsgroups, nor do I post there either. But if Greg Miller presists on this childish behaviour, I can post a few flames myself. But I dont want to do that. I like to consider myself above such jerkoff actions. You dont like the Atari, get the fuck away, and shut the hell up, yes? I dont like computer wars, and I am sure there are others who feel the same, but if youll notice, many Atari VS Amiga wars in comp.sys.atari.st are started by AMIGA GEEKS! In a thread some bit back, titled Atarians, where are you. I posted that I would consider an Amiga as a computer (I dont own just one, I own at least 20 different kinds, and the Amiga would be just another collection), but I do not want myself linked to people of such low mentality. Do I judge too hashly? I dunno, but out of 10 Amiga users I met, they all act the same. Its like a fucking brain virus. Enough said. Flames, comments, etc, to /dev/null. If you (an Amiga user) reads this, and gets mad and wishes to flame me, dont bother) Billy D'Augustine Azog-Thoth@cup.portal.com PS: To Greg Miller: I own a brand new 520STe, with 4mb of RAM, and TOS 1.62, and Ive yet to come across a program that wont run on it. I cannot play some games, simply because I do not have a colour monitor. And dont bother starting stupid wars about the different monitors. Your an asshole ------------------------------ Date: 24 Jan 92 04:01:35 GMT From: mintaka.lcs.mit.edu!hal.gnu.ai.mit.edu!rjc@yale.arpa (Ray) Subject: Atarians! Where Are You?! To: Info-Atari16@naucse.cse.nau.edu In article <25611@skye.dcs.ed.ac.uk> kc@dcs.ed.ac.uk (Kenneth Cameron) writes: >In article <1992Jan23.071233.10605@milton.u.washington.edu> > ... (Jeremy C. Norberg) writes: >>Since the Amiga is a TRUE multitasking machine, we can do more than one thing >>at a time. Try THAT with your ST! (and don't even bother mentioning >>multigem.... That's about as good a multitasker as switcher is on the Mac) > >You know how the Amiga fanatics flaunt the fact that they have a TRUE >multitasking machine. Well, apparently when two processes decide to >access the floppy, they do just that, and the head runs up and down the >disk as each moves it back and forward never getting where they want. >Eventually ( after several seconds ) they time out and after a pause one >restarts first and manages to complete the operation. This part is wrong. The head walks back and forth between the areas of the disk where the accessed data is. The difference on the Amiga is, AmigaDOS (actually trackdisk.device) buffers and caches entire tracks when it needs to access single sector. Unless the disk is heavily framented there isn't much of a problem. There also isn't much of a solution. This subject was debated at length a few months ago in the Amiga groups and the conclusion was (verified by benchmarks on other systems) that disk head schleduling algorithms offer little improvement on floppies, especially fragmented disks. The best solution is a cache. >Can you say elavator algorithm ?, the Amiga systems programmers did n't. >(I think the machine by friend bought was new, so this is the current >release of the OS :-) You are wrong. The head doesn't ping pong without reaching it's destination. The head reads some data, runs back to the other side of the disk, reads some more, etc. When the Amiga accesses a sector, it ALWAYS reads in the entire track and caches it. You can get a simple improvement just by doing a "addbuffers" command. >-- >Kenneth@Edinburgh >Any opinions expressed above are mine, Edinburgh University can't afford any of >their own at the moment. ------------------------------ Date: 24 Jan 92 04:42:08 GMT From: mintaka.lcs.mit.edu!hal.gnu.ai.mit.edu!rjc@yale.arpa (Ray) Subject: Atarians! Where Are You?! To: Info-Atari16@naucse.cse.nau.edu In article <1992Jan23.132827.48664@link-1.ts.bcc.ac.uk> ucacmsu@ucl.ac.uk (Mr Stephen R Usher) writes: >In article <1992Jan23.071233.10605@milton.u.washington.edu> tlk@hardy.u.washington.edu (Jeremy C. Norberg) writes: >>In article <1992Jan18.122843.10678@actrix.gen.nz> Roger.Sheppard@actrix.gen.nz (Roger Sheppard) writes: >>> >>>Also I here that the sales of A500 + is now gone minus, they are all taking >>>them back as they can't play games on this new machine any more..?? >>> >> >>Kinda like the monstrosity known as the STe??? TOS 1.06 hardly runs anything!! >>Also, how many of your ST GAMES run on your beloved TT?? > >How many games will run on the A3000? I suspect none which assume that the >processor is a 68000 or which assume that the hardware is theirs alone to >play with. If they don't run, it's the software authors who should be >blamed, not the hardware. Commodore has STRONGLY warned developers not to use self-modifying code, mess with the MMU, use cpu busy-loops for delay, etc since 1986. That's why there's OS calls like GetCC() and CacheClear(). That's the real difference between the Mac/ST and the Amiga. The Mac used to pass data in the upper 8 bits of an address register probably because Apple never foresaw full 32-bit addressing. And alot of ST stuff uses priveleged instructions like move SR,. Only the real old european game hacks don't work too well. When did atari set down CPU rules like don't use move sr,ea, don't put data in the upper 8 bits of address registers, don't use cpu busy loops (because they are CPU speed and ram speed dependent), don't use self-modifying code? >> >>>And were are all your PD C compilers, this main Amiga chaps here don't >>>seem to know much about them.. >>> >> >>The amiga doesn't NEED a PD compiler. There are still publishers that >>support us!! > >EVERY platform needs a PD C compiler unless it comes with one as standard, >this allows poor people who can only afford the bare machine to contribute >to the community. Well the Amiga has plenty of PD C compilers, I'll list the compilers I know about. PDC (PD) Sozobon (PD) GCC (PD) C68k (PD) DICE (PD) NorthC (PD) Lattice/SASC (Commercial) Manx C (Commercial) Comeau C++ (Commercial) There are probably some more thatr I left out, however GCC and DICE beat all the PD compilers. DICE is more Amiga specific. (BTW, the author of DICE, Matt Dillon, is porting BSD 4.4 to the Amiga as FreeWare! Don't think he can't do it either, Matt has single handedly programmed over 20 Amiga developer tools as freeware.) >> >PS. The Amiga is a fine machine for graphics, and quite good for sound, but >it isn't ideal for some things, including I must say, programming in C. You're gonna have to justify this statement. The Amiga has more programming tools than I can count. Numerous C compilers, 4 Forth implementations, Modula-2, Oberon, Smalltalk, Eiffel, Lisp/Scheme, Basic (plentity of them including ones that produce optimized assembly), AMOS, Fortran, the list goes on. Almost every language has been ported. There are a couple PD interface builders for GUI work, PD debuggers, not to mention that AmigaDOS looks and smells like Unix from the shell point of view. There is an entire (PD)C programming manual on disk that teaches Amiga programming step by step. Not to mention the 590 fish disks FULL of programs with C source code. I'd say the Amiga is the second best computer to program C on besides the NeXT. >-- >Addresses:- >JANET:- ucacmsu@uk.ac.ucl or susher@uk.ac.csm >Internet:- ucacmsu@ucl.ac.uk or susher@csm.ac.uk ------------------------------ Date: 23 Jan 92 23:48:05 GMT From: fernwood!portal!cup.portal.com!Azog-Thoth@uunet.uu.net (William Thomas Daugustine) Subject: blitter questions To: Info-Atari16@naucse.cse.nau.edu Hiyas. Ive got a 520STe and am wondering if there is a program of some sort that I could run to see the difference between turning the blitter on and off. I chose blitter on from the desktop, and from any program I run thatll accept it, but I am just wondering just exactly what it does... (I dont see a difference between when I turn it off, try things, and turn it on again... btw: if it makes any difference, I am using a mono monitor) Thanx Billy D'Augustine Azog-Thoth@cup.portal.com ------------------------------ Date: 23 Jan 92 13:46:49 GMT From: noao!ncar!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.e du!ohstpy!miavx1!rlcollins@arizona.edu (Ryan 'Gozar' Collins) Subject: Hyperformat disk on a PC To: Info-Atari16@naucse.cse.nau.edu In article <1992Jan21.145114.25642@unibi.uni-bielefeld.de>, itschere@techfak.uni-bielefeld.de (Torsten Scherer) writes: > In article <12475@star.cs.vu.nl>, rfschaa@cs.vu.nl (Schaaf RF) writes: > |> I have been using hyperformatted disks (11-sectors/track) ever > |> since I bought Scheibenkleister. A few weeks ago I bought a PC > |> and assumed the High density drive would be able to handle 11 > |> sectors per track. I was wrong, I am unable to read the disks. > |> Does anyone know whether it is possible to read Hyperformatted > |> disk on a PC. The problem isn't DOS (PC-speed works fine with > |> these disks), so what is the problem? > > You're right, it's not a DOS problem. You can even add lines > like "device=driver.sys /d:1 /t:80 /s:11" to your config.sys and > it will work on an emulator on ST's. Maybe up to 10 sectors this > also works on "normal" PC's, but definitely not with 11-sector-disks, > because the standard PC floppy controller is unable to read/write 11 > sectors on a DD disk. Well, it also depends on the PC. My roomates Zentih with a HD drive could read the extended formats. (I don't know if I've tried 11 sectors, maybe I'll do that tonight and find out.) We joked about how his Zenith could read and write to my ST disks, saying the computer had the "Atari Spirit!!" I haven't tried it with a PS/2 or anything though. But I know the Zentih could read 10 sectors/80 tracks. (CHKDSK came back with 800K free on the disk.) Later....... ------======={{{{{{{{((((((Ryan 'Gozar' Collins))))))))}}}}}}}}=======-------- Atari Computers: "The Game is never over" rlcollins@miavx1.BITNET Power Without The Price R.COLLINS1 on GEnie ------======={{{{{{{{(((((( My 1040STF Rocks!! ))))))))}}}}}}}}=======-------- ------------------------------ Date: 24 Jan 92 01:48:45 GMT From: noao!ncar!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!wupost!waikato.ac.nz !comp.vuw.ac.nz!actrix!Roger.Sheppard@arizona.edu (Roger Sheppard) Subject: I cant get Zoo to work! To: Info-Atari16@naucse.cse.nau.edu In article <1992Jan22.094433.9780@topaz.ucq.edu.au> johnsonc@topaz.ucq.edu.au writes: > In article <9201192315.aa15112@Bonnie.ics.uci.edu>, ehohnbau@Bonnie.ICS.UCI.EDU writes: > > > > I've been trying to get Zoo.ttp to work for the last couple of days > > and even with the recent postings I can't get it to work. > > I've tried the following with both zoo.ttp and the file zooboy.zoo > > in the root directory of the a: drive: > > > > After I click on zoo.ttp and the the parameter box I tried: > > > > x zooboy.zoo > > x zooboy > > x [aA]:[\] zooboy[.zoo] > > In other words, I tried both with and without the .zoo extender > > on every other option, and I tried both upper and lower case on the > > drive option, and with and without the backslash. > > > > The only thing that happens is that it takes me right back to the > > GEM desktop. > > > > zooboy is supposed to be a graphical interface for zoo but you need > > to be able to use zoo to unzoo Zooboy!!!!! #@&*%$!! > > > > I'd dearly appreciate someone mailing me a way out of this! > > > > Thanx, > > Eric Hohnbaum > > It's not the best solution about but what I do is copy the .zoo file to > an IBM disk, put in PC-DITTO and run the IBM version of Zoo 2.1 on the .zoo > file. It's okay if you have the emulator but I thought I'd tell everyone > anyway as the algorithms between machine versions (IBM and ST) appear to > the same for LHARC (but not the PC's LHA), (ARC and PKXARC[?]) and > (UUD and UUDECODE). >> It's slow but does the trick. > Chris. NO ! this is like going backwards, get the arcgsh40.zoo from A.A. this will make like easyer.. -- *** Roger W. Sheppard * Roger.Sheppard@bbs.actrix.gen.nz *** *** 85 Donovan Rd * * GEnie. R.SHEPPARD5 *** *** Kapiti At least I don't Flicker, *** *** New Zealand.. * not like a dying light globe *** ------------------------------ Date: 23 Jan 92 23:56:20 GMT From: psinntp!ultb!ritvax.isc.rit.edu!JWS7793@uunet.uu.net Subject: Model questions To: Info-Atari16@naucse.cse.nau.edu I am new to the Atari ST line of computers. I posted a note earlier asking for any cheap ST's for sale. I have had some offers. If you have one for sale send Email. Anyway what I would like to know is what is the difference between a 520 ST FM and a 520 STe? If someone wouldn't mind giving a run down of all of the ST models spec-wise that'd be cool too. Thanks for your time. James ------------------------------ Date: 24 Jan 92 02:46:46 GMT From: boulder!csn!cherokee!agni!tls@uunet.uu.net (Terry Simmons) Subject: Multifinder for Atari-ST ? To: Info-Atari16@naucse.cse.nau.edu In article <1992Jan23.133054.6471@cs.nott.ac.uk> dpg@cs.nott.ac.uk (`Grave' Dave Gymer) writes: >In article <29446@imag.imag.fr> maraninx@imag.fr (Florence Maraninchi) writes: >>I need something like the equivalent of the Macintosh multifinder ... >>Does it exist ? > >Not really. Yet. > I was just reading an add in the ST Informer about MultiGem which claims to be just like a multifinder for the ST. Having never used MultiGem or Multifinder could someone else shed some light on this subject? Thanx Terry PS the views expressed here are my own and are probably not understood by my employer. -- ============================================================================= Terry Simmons e-mail tls@uswest.com U S WEST Advanced Technologies ------------------------------ Date: 24 Jan 92 02:14:29 GMT From: noao!ncar!elroy.jpl.nasa.gov!usc!wupost!waikato.ac.nz!comp.vuw.ac.nz!actrix!Rog er.Sheppard@arizona.edu (Roger Sheppard) Subject: New Supra Modem... To: Info-Atari16@naucse.cse.nau.edu In article <1992Jan23.171744.29869@watserv1.waterloo.edu> jparker@caddac1.waterloo.edu (James Parker) writes: > In article <1992Jan23.102316.400@actrix.gen.nz> Roger.Sheppard@actrix.gen.nz (Roger Sheppard) writes: > >In article <1992Jan22.194723.23878@milton.u.washington.edu> tymbrimi@milton.u.washington.edu (Ben Gilbert) writes: > >> Hi, I recently saw an ad in a friend's computer magazine for a new > >> Supra modem, something like the Supra 2400 PLUS, it says it has > >> asynchronous 300,1200,2400 bps (that's the usual I suppose), 4800 bps > >> with MNP 5, and 9600 bps with v32.bis or v42.bis (can't remember which). > >> So can I actually pay the CHEAP $130 bucks for this modem and dial up > >> my school net at 9600 baud? Sounds like a good deal to me, I know that > >> my school dial-in IS this new v32(42).bis thing, someone tell me, 9600 > >> baud would be awesome for only $130 mail order... > >> > > I have a somewhat related question concerning my Supra 2400 modem. > I have been using it satisfactorily for several years until recently > new modems were installed on the server here at the university. > Now I cannot connect at 2400 baud (tho' it does still work at 1200). > > According to the docs, the dial-in lines use V.42bis at 2400 baud. > My Supra 2400 manual says it is V.22bis. Is there an inherent > incompatibility here? Do I need to get a new modem using V.42bis > to talk at 2400? Please say no! I know nil about what V.42, V.22 etc > means so be easy on me. > > thanks for any help. > james > Well it should not be this way, V42 is a error correcting protocal and V42 bis is a compression Protocal, you have a option to turn them off/on, they are not part of the line standard, that is your V22, if the don't let you connect then I would say that the system has been programed incorrectly.. Check to see if there new modems support that line standard V22... -- *** Roger W. Sheppard * Roger.Sheppard@bbs.actrix.gen.nz *** *** 85 Donovan Rd * * GEnie. R.SHEPPARD5 *** *** Kapiti At least I don't Flicker, *** *** New Zealand.. * not like a dying light globe *** ------------------------------ Date: 23 Jan 92 18:54:00 GMT From: imagen!atari!apratt@sun.com (Allan Pratt) Subject: PRGFLAGS review (was talk about Tcsh) To: Info-Atari16@naucse.cse.nau.edu This is a review of what PRGFLAGS means; some people don't know and are asking. Starting with TOS 1.4, a previously-undefined field of the program header (the first 0x1c bytes of every program file) acquired a meaning. It's called PRGFLAGS, and contains bits and numeric fields which control various things about the program. The fast-load bit is Bit 0 in the PRGFLAGS field. Normally it is clear. When it's clear, or if your TOS is older than 1.4, then all the memory the process starts out with is cleared before the process is started. This includes the BSS space that the program declared, and also the "heap" space between the end of the BSS and the top of the memory the process gets. Clearing this memory takes time, especially on a 4MB 68000 machine. If you set the "fast-load" bit, TOS 1.4 and newer will save time by not bothering to clear the "heap" memory. It still clears the BSS -- the BSS is guaranteed to be clear when your program starts up. Nobody ever guaranteed that the "heap" would be clear, but the original GEMDOS cleared it, and some programs rely on this, either on purpose (i.e. the programmer knew it would be clear and was counting on it) or by accident (the program has a bug in which, for example, an uninitialized field of a structure obtained from malloc() is expected to be zero). Thus, for compatibility, the default action is to go on clearing this memory, and if you ask for it (by setting that bit) the memory won't be cleared, and the program will start faster. Bits 1 and 2 of PRGFLAGS are concerned with the eligibility of alternative RAM for loading the program and for satisfying Malloc calls, respectively. The concept of alternative RAM comes into play if there is memory in your machine which is not like ST RAM. This is the case in TT's and in some 68030 accelerator systems. Also, bits 28-31 encode a four-bit number which is also used when deciding whether to load the program in alternative RAM. All other bits in the PRGFLAGS field of the program header are reserved for use by Atari, and should be set to zero unless you know what you're doing. There is a program from Atari called PRGFLAGS which lets you examine and set the flags in the headers of your program files. Check for it on atari.archive, local archive servers, or the Atari roundtable on GEnie. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt ------------------------------ Date: 24 Jan 92 01:45:02 GMT From: noao!ncar!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!th ink.com!wupost!waikato.ac.nz!comp.vuw.ac.nz!actrix!Roger.Sheppard@arizona.edu (Roger Sheppard) Subject: Rom chip set switch time? To: Info-Atari16@naucse.cse.nau.edu In article <9201222340.aa17848@Bonnie.ics.uci.edu> ehohnbau@Bonnie.ICS.UCI.EDU writes: > > I've got a 1040 at least 5 years old and I'm pretty sure it has the 6-chip > Rom set but I'm not certain and I'd rather not open it up if I don't have to. > I'm looking to buy a set of 1.4 chips (used if anyone is wanting to sell) > but I need to be sure if mine is the 6 chip set. > > Can anyone tell me for sure when the switch was made from the 6 to the > 2 chip set? This machine was made before the Mega's came out because my > Grandfather gave me this when he got his new Mega not too long after the > Mega's came out. > > Thanx Get a copy of the install docs, there are some 3/4 mother boards shown, and some to me look very old, like rames under the left of the keyboard -- *** Roger W. Sheppard * Roger.Sheppard@bbs.actrix.gen.nz *** *** 85 Donovan Rd * * GEnie. R.SHEPPARD5 *** *** Kapiti At least I don't Flicker, *** *** New Zealand.. * not like a dying light globe *** ------------------------------ Date: 23 Jan 92 09:34:11 GMT From: noao!ncar!elroy.jpl.nasa.gov!usc!apple!well!dsmall@arizona.edu (David Small) Subject: SST shipdate & Gadgets news To: Info-Atari16@naucse.cse.nau.edu Here's some updates on the SST, Spectre, MegaTalk, and so forth, for those who aren't on the GEnie / Compuserve networks (was posted there this week). We expect to start shipping SST's this week, barring Murphy's law causing some minor problem. The software, hardware, and manuals are ready, as well as a lot of mailing labels ... :-) We're sorry for the delay in shipping. It was vital to track down a serious bug in the hard disk "life support" for hard disks that were SST RAM (fastram) unaware; it turned out to be a buffer overlaying code. But it took weeks to nail down and led me down many false paths. Fun. Several people have asked about the manual. Currently it is 2.8 megabytes long in Quark X*Press on Sandy's Mac. It works out to around 140 pages, plus or minus a few, on 8 1/2 x 11 paper. It's our best ever, with plenty of interludes. MegaTalk was held up on its production run by having one PAL on every board be bad, probably from the factory. (SST had 4 bad GAL's from the factory -- what's this Built in America stuff? Sheesh, talk about getting good at switching chips). The MegaTalk batch here is about 75% tested, and once you replace the PAL controlling serial I/O, they work fine. They'll ship as soon as we get the SST shipping smoothly; both are backlogged "to the gills" <-- Americanism. Spectre is still at 3.0. Work is being done now on TT SCSI hard disks so the internal drive and other SCSI devices can be accessed; that'll take a little doing but isn't the end of the world. The code to fix the cached accelerator bug on <4 meg machines is very minor (10 minutes?). Finally, System 7 is giving me absolute conniption fits as I trace it, with the ZAX set to "twang" and stop on any access to location 0 (typical Zerostore goblins); I don't understand why any sane programmer would read the entire contents of battery-backed up extended parameter RAM into location 0 on up, thus destroying all the 68000 exception vectors. I'll fix that one, and keep on slogging through until the thing boots up and quits hallucinating about its available memory (current symptom). Problem is, I have NO WAY to predict how many bugs lie between where I am now and bootup time; I just have to fix one and let it "G"o, and see where it crashes NeXT ... *grin*. It's like debugging anything else, I guess. This means, in simple terms, Spectre 3.1 does not exist. Anyone advertising it? I have heard rumours. It just plain does not exist. It's been an interesting few weeks, as you might imagine, and I've seen plenty of Colorado sunrises since I can get work done at night. I have not been on the Net as much as I would like, nor any network; I have had to focus time on SST's hard disk snag, as that was holding up the manual and the disks, and it turned out to be difficult. (ST-Report ran the final story; it's around 450 lines of text.) I'll try to be answering back e-mail over the next few days; I still have a couple minor "clean up" things to do (READ.ME files on the release disks, for instance.). Currently, SST is at version 1.21. We will begin the sixth Gadgets Newsletter as soon as I have something to report on 3.1. I believe we are planning on FREE distribution of 3.1 unless something comes up to snag it (I can remember someone claiming that posting s/w to the nets made it "public domain" ... yeah, right). I don't know if the size, around 400K, will overload the net; I can't FTP and never have, and don't know that side of things whatsoever. Maybe someone can let me in on it. I'd like to get 3.1 around as quickly as possible. Finally, we have isolated several different problems that TT's can have with GCR's. Briefly, they are: * The floppies are getting EMI from the monitor -- move it. * The cartridge port fuse, on the +5 line, is blown. Common. Check pins 14 and 28 for 0 and +5 volts (or close) respectively. * The floppy drives may not be 100% if you have the caches on. A lot depends on how fast the 68030 runs, which can depend on if the program ends up paragraph aligned at a critical point. (True!) Try clicking the caches off from the Spectre menu. * DO NOT TT-RAM flag SPECTRE.PRG, LAUNCH.PRG, or GCRTEST.PRG. * Finally, there can be a timing bug that relates to 68030's in general and the GCR. It really all depends on the particular TT and on a particular chip's speed in the GCR; if your GCR works, don't fix it!!! We have a fix for this timing snag that appears to cure this problem after much testing. I will try to get it from GEnie and upload it here. It involves adding one IC piggyback and an RC network for fine tuning. In the USA a "fix" involving piggybacking 7406 chips was published by Atari User; no one checked with us. We have no idea why this would affect the GCR on the TT whatsoever, and have talked to people who have gone to the trouble of making the change to find it makes no difference. HONEST, the 7406 is NOT IN THE PATH OF THE MAC DATA being made by the GCR and sent to the disk; the GCR drives the write-data line directly! I do not understand what this 7406 fix is about. We have built up several hundred modified GCR's for TT's (they also work on ST's still!) and are getting them into the pipeline. Sorry for the overly long note; I had to route MANY rumours to /dev/rumour/null. -- thanks, Dave Small / Tired Bottle Washer / Gadgets by Small, Inc. GEnie: DAVESMALL CIS: 76004,2136 Here: dsmall@well.sf.ca.us FAX: USA (303) 791-0253, phone (303) 791-6098 mon-wed-fri (it is often busy). ------------------------------ Date: 24 Jan 92 01:39:45 GMT From: noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!wupost!waikato.ac.nz!comp.vuw.ac.nz!act rix!Roger.Sheppard@arizona.edu (Roger Sheppard) Subject: What to do? To: Info-Atari16@naucse.cse.nau.edu In article <4f3rxzd@rpi.edu> pinelr@aix.rpi.edu (Robert Jeffrey Pinelli) writes: > In article <1992Jan23.031750.19244@verdix.com> scotty@verdix.com (Scott R. Chilcote) writes: > > > >Hey, Ken, this isn't as twisted as it sounds! > > --Rob > > p.s. To get an idea how old my mega is, it has the 6 chip ROM set in it that > almost NO Megas have! Boy am I glad I didn't take Toad Computer's word for > it when ordering my TOS 1.4 upgrade! > Can you tell me what the problem was , as these machines can take both, the 2 chip set is far better as it has less buss loading.. The only problem could be with very old ST's and ones with 2 rom sockets as they can only take this 2 chip set, with out adding the extra sockets.. -- *** Roger W. Sheppard * Roger.Sheppard@bbs.actrix.gen.nz *** *** 85 Donovan Rd * * GEnie. R.SHEPPARD5 *** *** Kapiti At least I don't Flicker, *** *** New Zealand.. * not like a dying light globe *** ------------------------------ Date: 24 Jan 92 02:02:04 GMT From: noao!ncar!elroy.jpl.nasa.gov!usc!wupost!waikato.ac.nz!comp.vuw.ac.nz!actrix!Rog er.Sheppard@arizona.edu (Roger Sheppard) Subject: Yet another ST for sale To: Info-Atari16@naucse.cse.nau.edu In article <31717@natinst.natinst.com> glens@natinst.com (Glen Sescila) writes: > england@u.washington.edu writes ... > > > Heh heh.... Like a rat scrambling to abandon a sinking ship, yet another > > Atarian offers up his 'computer' hoping that some fool will be stupid enough > > to buy it. > > I just wanted to mention that I can see at least 4X as many Amigas > for sale per week as Ataris. In fact they had to create a whole seperate > newsgroup just for unloading Amigas! Well I quoted negative sales, meaning that they are taking there A500 Plus back to the shops as they don't play games any more. One shop here stated to me that only 2 games in the shop would work on the New A500 +. The games that are packed with the machine, most don't work, Commodore include a list with the machine of the games that don't work.. And even Lemmings does not work, is that a old game..?? All this has been confirmed by 2 other Amiga Shops here Hey this new work bench that they have still can't lasso files, to copy or delete.. And they still use Sum Checks on all there disks..!! > > Heh heh.... > ----------------------------------------------------------------------------- > "Now You're Playing With Power Without The Price!" Glen Sescila ||| > / | \ > My opinions do not necessarily reflect those of my employer and probably are > exact opposites. glens@natinst.com > ----------------------------------------------------------------------------- -- *** Roger W. Sheppard * Roger.Sheppard@bbs.actrix.gen.nz *** *** 85 Donovan Rd * * GEnie. R.SHEPPARD5 *** *** Kapiti At least I don't Flicker, *** *** New Zealand.. * not like a dying light globe *** ------------------------------ End of Info-Atari16 Digest ******************************